home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2230.txt < prev    next >
Text File  |  1997-11-11  |  26KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         R. Atkinson
  8. Request for Comments: 2230                                            NRL
  9. Category: Informational                                     November 1997
  10.  
  11.  
  12.                Key Exchange Delegation Record for the DNS
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard of any kind.  Distribution of this
  18.    memo is unlimited.
  19.  
  20. Copyright Notice
  21.  
  22.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  23.  
  24. ABSTRACT
  25.  
  26.    This note describes a mechanism whereby authorisation for one node to
  27.    act as key exchanger for a second node is delegated and made
  28.    available via the Secure DNS.  This mechanism is intended to be used
  29.    only with the Secure DNS.  It can be used with several security
  30.    services.  For example, a system seeking to use IP Security [RFC-
  31.    1825, RFC-1826, RFC-1827] to protect IP packets for a given
  32.    destination can use this mechanism to determine the set of authorised
  33.    remote key exchanger systems for that destination.
  34.  
  35. 1. INTRODUCTION
  36.  
  37.  
  38.    The Domain Name System (DNS) is the standard way that Internet nodes
  39.    locate information about addresses, mail exchangers, and other data
  40.    relating to remote Internet nodes. [RFC-1035, RFC-1034] More
  41.    recently, Eastlake and Kaufman have defined standards-track security
  42.    extensions to the DNS. [RFC-2065] These security extensions can be
  43.    used to authenticate signed DNS data records and can also be used to
  44.    store signed public keys in the DNS.
  45.  
  46.    The KX record is useful in providing an authenticatible method of
  47.    delegating authorisation for one node to provide key exchange
  48.    services on behalf of one or more, possibly different, nodes.  This
  49.    note specifies the syntax and semantics of the KX record, which is
  50.    currently in limited deployment in certain IP-based networks.  The
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Atkinson                     Informational                      [Page 1]
  59.  
  60. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  61.  
  62.  
  63.    reader is assumed to be familiar with the basics of DNS, including
  64.    familiarity with [RFC-1035, RFC-1034].  This document is not on the
  65.    IETF standards-track and does not specify any level of standard.
  66.    This document merely provides information for the Internet community.
  67.  
  68. 1.1 Identity Terminology
  69.  
  70.    This document relies upon the concept of "identity domination".  This
  71.    concept might be new to the reader and so is explained in this
  72.    section.  The subject of endpoint naming for security associations
  73.    has historically been somewhat contentious.  This document takes no
  74.    position on what forms of identity should be used.  In a network,
  75.    there are several forms of identity that are possible.
  76.  
  77.    For example, IP Security has defined notions of identity that
  78.    include: IP Address, IP Address Range, Connection ID, Fully-Qualified
  79.    Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
  80.    FQDN).
  81.  
  82.    A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
  83.    turn dominates an IP Address identity.  Similarly, a Connection ID
  84.    dominates an IP Address identity.  An IP Address Range dominates each
  85.    IP Address identity for each IP address within that IP address range.
  86.    Also, for completeness, an IP Address identity is considered to
  87.    dominate itself.
  88.  
  89. 2. APPROACH
  90.  
  91.    This document specifies a new kind of DNS Resource Record (RR), known
  92.    as the Key Exchanger (KX) record.  A Key Exchanger Record has the
  93.    mnemonic "KX" and the type code of 36.  Each KX record is associated
  94.    with a fully-qualified domain name.  The KX record is modeled on the
  95.    MX record described in [Part86]. Any given domain, subdomain, or host
  96.    entry in the DNS might have a KX record.
  97.  
  98. 2.1 IPsec Examples
  99.  
  100.    In these two examples, let S be the originating node and let D be the
  101.    destination node.  S2 is another node on the same subnet as S.  D2 is
  102.    another node on the same subnet as D.  R1 and R2 are IPsec-capable
  103.    routers.  The path from S to D goes via first R1 and later R2.  The
  104.    return path from D to S goes via first R2 and later R1.
  105.  
  106.    IETF-standard IP Security uses unidirectional Security Associations
  107.    [RFC-1825].  Therefore, a typical IP session will use a pair of
  108.    related Security Associations, one in each direction.  The examples
  109.    below talk about how to setup an example Security Association, but in
  110.    practice a pair of matched Security Associations will normally be
  111.  
  112.  
  113.  
  114. Atkinson                     Informational                      [Page 2]
  115.  
  116. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  117.  
  118.  
  119.    used.
  120.  
  121. 2.1.1 Subnet-to-Subnet Example
  122.  
  123.    If neither S nor D implements IPsec, security can still be provided
  124.    between R1 and R2 by building a secure tunnel.  This can use either
  125.    AH or ESP.
  126.  
  127.        S ---+                                          +----D
  128.             |                                          |
  129.             +- R1 -----[zero or more routers]-------R2-+
  130.             |                                          |
  131.        S2---+                                          +----D2
  132.  
  133.        Figure 1:  Network Diagram for Subnet-to-Subnet Example
  134.  
  135.    In this example, R1 makes the policy decision to provide the IPsec
  136.    service for traffic from R1 destined for R2.  Once R1 has decided
  137.    that the packet from S to D should be protected, it performs a secure
  138.    DNS lookup for the records associated with domain D.  If R1 only
  139.    knows the IP address for D, then a secure reverse DNS lookup will be
  140.    necessary to determine the domain D, before that forward secure DNS
  141.    lookup for records associated with domain D.  If these DNS records of
  142.    domain D include a KX record for the IPsec service, then R1 knows
  143.    which set of nodes are authorised key exchanger nodes for the
  144.    destination D.
  145.  
  146.    In this example, let there be at least one KX record for D and let
  147.    the most preferred KX record for D point at R2.  R1 then selects a
  148.    key exchanger (in this example, R2) for D from the list obtained from
  149.    the secure DNS.  Then R1 initiates a key management session with that
  150.    key exchanger (in this example, R2) to setup an IPsec Security
  151.    Association between R1 and D.  In this example, R1 knows (either by
  152.    seeing an outbound packet arriving from S destined to D or via other
  153.    methods) that S will be sending traffic to D.  In this example R1's
  154.    policy requires that traffic from S to D should be segregated at
  155.    least on a host-to-host basis, so R1 desires an IPsec Security
  156.    Association with source identity that dominates S, proxy identity
  157.    that dominates R1, and destination identity that dominates R2.
  158.  
  159.    In turn, R2 is able to authenticate the delegation of Key Exchanger
  160.    authorisation for target S to R1 by making an authenticated forward
  161.    DNS lookup for KX records associated with S and verifying that at
  162.    least one such record points to R1.  The identity S is typically
  163.    given to R2 as part of the key management process between R1 and R2.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Atkinson                     Informational                      [Page 3]
  171.  
  172. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  173.  
  174.  
  175.    If D initially only knows the IP address of S, then it will need to
  176.    perform a secure reverse DNS lookup to obtain the fully-qualified
  177.    domain name for S prior to that secure forward DNS lookup.
  178.  
  179.    If R2 does not receive an authenticated DNS response indicating that
  180.    R1 is an authorised key exchanger for S, then D will not accept the
  181.    SA negotiation from R1 on behalf of identity S.
  182.  
  183.    If the proposed IPsec Security Association is acceptable to both R1
  184.    and R2, each of which might have separate policies, then they create
  185.    that IPsec Security Association via Key Management.
  186.  
  187.    Note that for unicast traffic, Key Management will typically also
  188.    setup a separate (but related) IPsec Security Association for the
  189.    return traffic.  That return IPsec Security Association will have
  190.    equivalent identities.  In this example, that return IPsec Security
  191.    Association will have a source identity that dominates D, a proxy
  192.    identity that dominates R2, and a destination identity that dominates
  193.    R1.
  194.  
  195.    Once the IPsec Security Association has been created, then R1 uses it
  196.    to protect traffic from S destined for D via a secure tunnel that
  197.    originates at R1 and terminates at R2.  For the case of unicast, R2
  198.    will use the return IPsec Security Association to protect traffic
  199.    from D destined for S via a secure tunnel that originates at R2 and
  200.    terminates at R1.
  201.  
  202. 2.1.2 Subnet-to-Host Example
  203.  
  204.    Consider the case where D and R1 implement IPsec, but S does not
  205.    implement IPsec, which is an interesting variation on the previous
  206.    example.  This example is shown in Figure 2 below.
  207.  
  208.        S ---+
  209.             |
  210.             +- R1 -----[zero or more routers]-------D
  211.             |
  212.        S2---+
  213.  
  214.        Figure 2:  Network Diagram for Subnet-to-Host Example
  215.  
  216.    In this example, R1 makes the policy decision that IP Security is
  217.    needed for the packet travelling from S to D.  Then, R1 performs the
  218.    secure DNS lookup for D and determines that D is its own key
  219.    exchanger, either from the existence of a KX record for D pointing to
  220.    D or from an authenticated DNS response indicating that no KX record
  221.    exists for D.  If R1 does not initially know the domain name of D,
  222.    then prior to the above forward secure DNS lookup, R1 performs a
  223.  
  224.  
  225.  
  226. Atkinson                     Informational                      [Page 4]
  227.  
  228. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  229.  
  230.  
  231.    secure reverse DNS lookup on the IP address of D to determine the
  232.    fully-qualified domain name for that IP address.  R1 then initiates
  233.    key management with D to create an IPsec Security Association on
  234.    behalf of S.
  235.  
  236.    In turn, D can verify that R1 is authorised to create an IPsec
  237.    Security Association on behalf of S by performing a DNS KX record
  238.    lookup for target S.  R1 usually provides identity S to D via key
  239.    management.  If D only has the IP address of S, then D will need to
  240.    perform a secure reverse lookup on the IP address of S to determine
  241.    domain name S prior to the secure forward DNS lookup on S to locate
  242.    the KX records for S.
  243.  
  244.    If D does not receive an authenticated DNS response indicating that
  245.    R1 is an authorised key exchanger for S, then D will not accept the
  246.    SA negotiation from R1 on behalf of identity S.
  247.  
  248.    If the IPsec Security Association is successfully established between
  249.    R1 and D, that IPsec Security Association has a source identity that
  250.    dominates S's IP address, a proxy identity that dominates R1's IP
  251.    address, and a destination identity that dominates D's IP address.
  252.  
  253.    Finally, R1 begins providing the security service for packets from S
  254.    that transit R1 destined for D.  When D receives such packets, D
  255.    examines the SA information during IPsec input processing and sees
  256.    that R1's address is listed as valid proxy address for that SA and
  257.    that S is the source address for that SA.  Hence, D knows at input
  258.    processing time that R1 is authorised to provide security on behalf
  259.    of S.  Therefore packets coming from R1 with valid IP security that
  260.    claim to be from S are trusted by D to have really come from S.
  261.  
  262. 2.1.3 Host to Subnet Example
  263.  
  264.    Now consider the above case from D's perspective (i.e. where D is
  265.    sending IP packets to S).  This variant is sometimes known as the
  266.    Mobile Host or "roadwarrier" case. The same basic concepts apply, but
  267.    the details are covered here in hope of improved clarity.
  268.  
  269.        S ---+
  270.             |
  271.             +- R1 -----[zero or more routers]-------D
  272.             |
  273.        S2---+
  274.  
  275.        Figure 3:  Network Diagram for Host-to-Subnet Example
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Atkinson                     Informational                      [Page 5]
  283.  
  284. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  285.  
  286.  
  287.    In this example, D makes the policy decision that IP Security is
  288.    needed for the packets from D to S.  Then D performs the secure DNS
  289.    lookup for S and discovers that a KX record for S exists and points
  290.    at R1.  If D only has the IP address of S, then it performs a secure
  291.    reverse DNS lookup on the IP address of S prior to the forward secure
  292.    DNS lookup for S.
  293.  
  294.    D then initiates key management with R1, where R1 is acting on behalf
  295.    of S, to create an appropriate Security Association.  Because D is
  296.    acting as its own key exchanger, R1 does not need to perform a secure
  297.    DNS lookup for KX records associated with D.
  298.  
  299.    D and R1 then create an appropriate IPsec Security Security
  300.    Association.  This IPsec Security Association is setup as a secure
  301.    tunnel with a source identity that dominates D's IP Address and a
  302.    destination identity that dominates R1's IP Address.  Because D
  303.    performs IPsec for itself, no proxy identity is needed in this IPsec
  304.    Security Association.  If the proxy identity is non-null in this
  305.    situation, then the proxy identity must dominate D's IP Address.
  306.  
  307.    Finally, D sends secured IP packets to R1.  R1 receives those
  308.    packets, provides IPsec input processing (including appropriate
  309.    inner/outer IP address validation), and forwards valid packets along
  310.    to S.
  311.  
  312. 2.2 Other Examples
  313.  
  314.    This mechanism can be extended for use with other services as well.
  315.    To give some insight into other possible uses, this section discusses
  316.    use of KX records in environments using a Key Distribution Center
  317.    (KDC), such as Kerberos [KN93], and a possible use of KX records in
  318.    conjunction with mobile nodes accessing the network via a dialup
  319.    service.
  320.  
  321. 2.2.1 KDC Examples
  322.  
  323.    This example considers the situation of a destination node
  324.    implementing IPsec that can only obtain its Security Association
  325.    information from a Key Distribution Center (KDC).  Let the KDC
  326.    implement both the KDC protocol and also a non-KDC key management
  327.    protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
  328.    might have its own KX record pointing at the KDC so that nodes not
  329.    implementing the KDC protocol can still create Security Associations
  330.    with each of the client nodes of the KDC.
  331.  
  332.    In the event the session initiator were not using the KDC but the
  333.    session target was an IPsec node that only used the KDC, the
  334.    initiator would find the KX record for the target pointing at the
  335.  
  336.  
  337.  
  338. Atkinson                     Informational                      [Page 6]
  339.  
  340. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  341.  
  342.  
  343.    KDC.  Then, the external key management exchange (e.g. ISAKMP) would
  344.    be between the initiator and the KDC.  Then the KDC would distribute
  345.    the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
  346.    traffic itself could travel directly between the initiator and the
  347.    destination node.
  348.  
  349.    In the event the initiator node could only use the KDC and the target
  350.    were not using the KDC, the initiator would send its request for a
  351.    key to the KDC.  The KDC would then initiate an external key
  352.    management exchange (e.g. ISAKMP) with a node that the target's KX
  353.    record(s) pointed to, on behalf of the initiator node.
  354.  
  355.    The target node could verify that the KDC were allowed to proxy for
  356.    the initiator node by looking up the KX records for the initiator
  357.    node and finding a KX record for the initiator that listed the KDC.
  358.  
  359.    Then the external key exchange would be performed between the KDC and
  360.    the target node.  Then the KDC would distribute the resulting IPsec
  361.    Security Association to the initiator.  Again, IPsec traffic itself
  362.    could travel directly between the initiator and the destination.
  363.  
  364. 2.2.2 Dial-Up Host Example
  365.  
  366.    This example outlines a possible use of KX records with mobile hosts
  367.    that dial into the network via PPP and are dynamically assigned an IP
  368.    address and domain-name at dial-in time.
  369.  
  370.    Consider the situation where each mobile node is dynamically assigned
  371.    both a domain name and an IP address at the time that node dials into
  372.    the network.  Let the policy require that each mobile node act as its
  373.    own Key Exchanger.  In this case, it is important that dial-in nodes
  374.    use addresses from one or more well known IP subnets or address pools
  375.    dedicated to dial-in access.  If that is true, then no KX record or
  376.    other action is needed to ensure that each node will act as its own
  377.    Key Exchanger because lack of a KX record indicates that the node is
  378.    its own Key Exchanger.
  379.  
  380.    Consider the situation where the mobile node's domain name remains
  381.    constant but its IP address changes.  Let the policy require that
  382.    each mobile node act as its own Key Exchanger.  In this case, there
  383.    might be operational problems when another node attempts to perform a
  384.    secure reverse DNS lookup on the IP address to determine the
  385.    corresponding domain name.  The authenticated DNS binding (in the
  386.    form of a PTR record) between the mobile node's currently assigned IP
  387.    address and its permanent domain name will need to be securely
  388.    updated each time the node is assigned a new IP address.  There are
  389.    no mechanisms for accomplishing this that are both IETF-standard and
  390.    widely deployed as of the time this note was written.  Use of Dynamic
  391.  
  392.  
  393.  
  394. Atkinson                     Informational                      [Page 7]
  395.  
  396. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  397.  
  398.  
  399.    DNS Update without authentication is a significant security risk and
  400.    hence is not recommended for this situation.
  401.  
  402. 3. SYNTAX OF KX RECORD
  403.  
  404.    A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
  405.    record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
  406.    record is associated with a <domain-name> entry in the DNS.  A KX
  407.    record has the following textual syntax:
  408.  
  409.         <domain-name>  IN  KX  <preference> <domain-name>
  410.  
  411.    For this description, let the <domain-name> item to the left of the
  412.    "KX" string be called <domain-name 1> and the <domain-name> item to
  413.    the right of the "KX" string be called <domain-name 2>.  <preference>
  414.    is a non-negative integer.
  415.  
  416.    Internet nodes about to initiate a key exchange with <domain-name 1>
  417.    should instead contact <domain-name 2> to initiate the key exchange
  418.    for a security service between the initiator and <domain-name 2>.  If
  419.    more than one KX record exists for <domain-name 1>, then the
  420.    <preference> field is used to indicate preference among the systems
  421.    delegated to.  Lower values are preferred over higher values.  The
  422.    <domain-name 2> is authorised to provide key exchange services on
  423.    behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
  424.    record, an A record, or an AAAA record associated with it.
  425.  
  426. 3.1 KX RDATA format
  427.  
  428.    The KX DNS record has the following RDATA format:
  429.  
  430.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  431.     |                  PREFERENCE                   |
  432.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  433.     /                   EXCHANGER                   /
  434.     /                                               /
  435.     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  436.  
  437.    where:
  438.  
  439.    PREFERENCE      A 16 bit non-negative integer which specifies the
  440.                    preference given to this RR among other KX records
  441.                    at the same owner.  Lower values are preferred.
  442.  
  443.    EXCHANGER       A <domain-name> which specifies a host willing to
  444.                    act as a mail exchange for the owner name.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Atkinson                     Informational                      [Page 8]
  451.  
  452. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  453.  
  454.  
  455.    KX records MUST cause type A additional section processing for the
  456.    host specified by EXCHANGER.  In the event that the host processing
  457.    the DNS transaction supports IPv6, KX records MUST also cause type
  458.    AAAA additional section processing.
  459.  
  460.    The KX RDATA field MUST NOT be compressed.
  461.  
  462. 4. SECURITY CONSIDERATIONS
  463.  
  464.    KX records MUST always be signed using the method(s) defined by the
  465.    DNS Security extensions specified in [RFC-2065].  All unsigned KX
  466.    records MUST be ignored because of the security vulnerability caused
  467.    by assuming that unsigned records are valid.  All signed KX records
  468.    whose signatures do not correctly validate MUST be ignored because of
  469.    the potential security vulnerability in trusting an invalid KX
  470.    record.
  471.  
  472.    KX records MUST be ignored by systems not implementing Secure DNS
  473.    because such systems have no mechanism to authenticate the KX record.
  474.  
  475.    If a node does not have a permanent DNS entry and some form of
  476.    Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
  477.    fully authenticated to prevent an adversary from injecting false DNS
  478.    records (especially the KX, A, and PTR records) into the Domain Name
  479.    System.  If false records were inserted into the DNS without being
  480.    signed by the Secure DNS mechanisms, then a denial-of-service attack
  481.    results.  If false records were inserted into the DNS and were
  482.    (erroneously) signed by the signing authority, then an active attack
  483.    results.
  484.  
  485.    Myriad serious security vulnerabilities can arise if the restrictions
  486.    throuhout this document are not strictly adhered to.  Implementers
  487.    should carefully consider the openly published issues relating to DNS
  488.    security [Bell95,Vixie95] as they build their implementations.
  489.    Readers should also consider the security considerations discussed in
  490.    the DNS Security Extensions document [RFC-2065].
  491.  
  492. 5. REFERENCES
  493.  
  494.  
  495.    [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
  496.                August 1995.
  497.  
  498.    [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
  499.                RFC 1827, August 1995.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Atkinson                     Informational                      [Page 9]
  507.  
  508. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  509.  
  510.  
  511.    [Bell95] Bellovin, S., "Using the Domain Name System for System
  512.             Break-ins", Proceedings of 5th USENIX UNIX Security
  513.             Symposium, USENIX Association, Berkeley, CA, June 1995.
  514.             ftp://ftp.research.att.com/dist/smb/dnshack.ps
  515.  
  516.    [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
  517.                Security Extensions", RFC 2065, January 1997.
  518.  
  519.    [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
  520.                Authentication Service", RFC 1510, September 1993.
  521.  
  522.    [RFC-1035]  Mockapetris, P., "Domain names - implementation and
  523.                specification", STD 13, RFC 1035, November 1987.
  524.  
  525.    [RFC-1034]  Mockapetris, P., "Domain names - concepts and
  526.                facilities", STD 13, RFC 1034, November 1987.
  527.  
  528.    [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
  529.              the 5th USENIX UNIX Security Symposium, USENIX
  530.              Association, Berkeley, CA, June 1995.
  531.              ftp://ftp.vix.com/pri/vixie/bindsec.psf
  532.  
  533. ACKNOWLEDGEMENTS
  534.  
  535.    Development of this DNS record was primarily performed during 1993
  536.    through 1995.  The author's work on this was sponsored jointly by the
  537.    Computing Systems Technology Office (CSTO) of the Advanced Research
  538.    Projects Agency (ARPA) and by the Information Security Program Office
  539.    (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
  540.    era, Dave Mihelcic and others provided detailed review and
  541.    constructive feedback.  More recently, Bob Moscowitz and Todd Welch
  542.    provided detailed review and constructive feedback of a work in
  543.    progress version of this document.
  544.  
  545. AUTHOR'S ADDRESS
  546.  
  547.    Randall Atkinson
  548.    Code 5544
  549.    Naval Research Laboratory
  550.    4555 Overlook Avenue, SW
  551.    Washington, DC 20375-5337
  552.  
  553.    Phone: (DSN) 354-8590
  554.    EMail: atkinson@itd.nrl.navy.mil
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Atkinson                     Informational                     [Page 10]
  563.  
  564. RFC 2230           DNS Key Exchange Delegation Record      November 1997
  565.  
  566.  
  567. Full Copyright Statement
  568.  
  569.    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  570.  
  571.    This document and translations of it may be copied and furnished to
  572.    others, and derivative works that comment on or otherwise explain it
  573.    or assist in its implmentation may be prepared, copied, published
  574.    andand distributed, in whole or in part, without restriction of any
  575.    kind, provided that the above copyright notice and this paragraph are
  576.    included on all such copies and derivative works.  However, this
  577.    document itself may not be modified in any way, such as by removing
  578.    the copyright notice or references to the Internet Society or other
  579.    Internet organizations, except as needed for the purpose of
  580.    developing Internet standards in which case the procedures for
  581.    copyrights defined in the Internet Standards process must be
  582.    followed, or as required to translate it into languages other than
  583.    English.
  584.  
  585.    The limited permissions granted above are perpetual and will not be
  586.    revoked by the Internet Society or its successors or assigns.
  587.  
  588.    This document and the information contained herein is provided on an
  589.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  590.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  591.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  592.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  593.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Atkinson                     Informational                     [Page 11]
  619.  
  620.